Change types to not assume an arch#425
Merged
Reflejo merged 1 commit intoenvoyproxy:masterfrom Feb 6, 2017
Merged
Conversation
mattklein123
reviewed
Feb 4, 2017
Member
There was a problem hiding this comment.
can we keep uint64_t as the var type (prefer to not use auto outside of for loops for clarity)
Member
There was a problem hiding this comment.
uint64_t: length() returns that and we are trying to make sure it is 64-bit unsigned (prefer to not use size_t for the reasons you are trying to fix).
Contributor
Author
There was a problem hiding this comment.
Ah yeah my bad, I followed the wrong length() and thought it was size_t. Will fix
Contributor
Author
There was a problem hiding this comment.
Honestly I think we should change this signature to take uint64_t instead (I mean onDataSourceRead's signature); does that makes sense to you? I'm pushing that change instead.
source/common/memory/stats.cc
Outdated
Member
There was a problem hiding this comment.
Sorry are these changes required because MallocExtension takes size_t as param?
Contributor
Author
There was a problem hiding this comment.
yep, since the constraint is on GetNumericProperty I think is better to be explicit here for clarity if that makes sense; also this of course fails on Darwin since __SIZE_TYPE__ is unsigned long and uint64_t is unsigned long long
Reflejo
force-pushed
the
fix-types-mismatch
branch
from
f9175db to
2bea251
Compare
mattklein123
approved these changes
Feb 4, 2017
Member
|
@Reflejo please fix format and merge master |
Some of these types were assuming that `size_t == uint64_t` or that `uint64_t == unsigned long` but that's not universally true, some BSDs such as Darwin define uint64_t as unsigned long long which warns on literals that are defined as `UL`. Additionally there were also some assumptions made on the pch as to forward declarations. So I explicitly added some needed ones.
Reflejo
force-pushed
the
fix-types-mismatch
branch
from
2bea251 to
ace7d21
Compare
zuercher
pushed a commit
that referenced
this pull request
Jan 23, 2018
…#2387) Description: Extend the health check filter to optionally compute its HTTP response status based on whether at least a specified percentage of servers in a specified set of upstream clusters are healthy. Risk Level: Medium Testing: Unit tests included Docs Changes: #425 Release Notes: Included in this PR Fixes: #2362 API Changes: #417 Signed-off-by: Brian Pane bpane@pinterest.com
rshriram
pushed a commit
to rshriram/envoy
that referenced
this pull request
Oct 30, 2018
rshriram
pushed a commit
to rshriram/envoy
that referenced
this pull request
Oct 30, 2018
Automatic merge from submit-queue. Introduce new attribute connection.mtls **What this PR does / why we need it**: Introduce new mixer attribute "connection.mtls" which indicates whether connection is mutual TLS enabled. Add virtual function bool IsMutualTlsEnabledConnection() into http/check_data.h and tcp/check_data.h, and call this function inside AttributesBuilder::ExtractCheckAttributes(). Add another virtual function bool GetDestinationIpPort(std::string* ip, int* port) to report destination IP and port from HTTP filter. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes envoyproxy#426 **Special notes for your reviewer**: **Release note**: ```release-note ```
jpsim
pushed a commit
that referenced
this pull request
Nov 28, 2022
`Client` -> `HTTPClient` `Envoy` -> `EnvoyClient` `EnvoyBuilder` -> `EnvoyClientBuilder` Consistent with [this Android change](envoyproxy/envoy-mobile#424), and helps us to avoid naming collisions with the `Envoy` type and `Envoy` module namespace. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
jpsim
pushed a commit
that referenced
this pull request
Nov 29, 2022
`Client` -> `HTTPClient` `Envoy` -> `EnvoyClient` `EnvoyBuilder` -> `EnvoyClientBuilder` Consistent with [this Android change](envoyproxy/envoy-mobile#424), and helps us to avoid naming collisions with the `Envoy` type and `Envoy` module namespace. Signed-off-by: Michael Rebello <me@michaelrebello.com> Signed-off-by: JP Simard <jp@jpsim.com>
mathetake
added a commit
that referenced
this pull request
Mar 3, 2026
**Commit Message** After #325, the translator is not where the abstraction over :path is implemented, but it moved to the choice of processor. As a result, the translator interface has become effectively tied to a specific endpoint, notably /v1/chat/completion. This renames the `translator.Translator` interface accordingly not only to remove the unnecessary code path but also facilitates the implementation of additional features like metrics. **Related Issues/PRs (if applicable)** Follow up on #325 and contribute to #316 --------- Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some of these types were assuming that
size_t == uint64_tor thatuint64_t == unsigned longbut that's not universally true, some BSDs such as Darwin define uint64_t as unsigned long long which warns on literals that are defined asUL.Additionally there was also some assumptions made on the pch as to forward declaration. So I explicitly added some needed ones.